The Debian FTP-masters recently changed the way gzipped meta files are compressed in order to make them more efficient to update using the rsync option. This was done by adding the --rsyncable option when calling gzip. Consequence was however that when debmirror compressed Packages, Sources and Contents files after updating them by applying diffs, the md5sum of the gzipped file created by debmirror no longer matched the md5sum listed in the Release file (because debmirror did not use --rsyncable). Result was that debmirror would also download the full gzipped Packages, Sources and Contents files from the parent mirror, something the diffs are meant to avoid. Not nice. Anyway, this has been fixed in debmirror 2.4 which now by default also uses --rsyncable when gzipping the updated meta files. I've also uploaded a fixed version for Lenny (20070123lenny1), which should soon be available from proposed-updates and will be included in the next stable point release. For archives that also provide diffs (most archives don't have them) but do not have rsyncable gzipped files, the default options used when calling gzip can be overruled using the new option --gzip-options (only in version 2.4). Tip: if you are using the rsync method to download files, using --diff=none may well be more efficient now that the archive has rsyncable gzipped meta files. Version 2.4 also has a few other improvements and fixes. If you're currently using version 2.3.x an update to the new version is probably a good idea.

Ok so there were some reactions to the Call for help post. I had three direct offers for help in pkg-xfce, not sure if other teams had such propositions. Some people asked me to correct various number for the active contributors . Basically, the numbers are what the feeling I got from people working in those team. Julien Cristau wants me to correct the number of debian-x active contributors to 0. (yes, zero, that means nobody, nadie, personne). Basically he doesn't have time anymore, and Brice Goglin can't really keep up. So, for those who care about shiny X effects, and stuff like that, you help would be gladly appreciated (and no, you don't have to own each and every chipset in the world to give some time). Aurelien Jarno wants me to add that at the moment there are 2 (two) active libc contributors, plus one on GNU/Hurd and one on kfreebsd. Frans Pop wants me to add that there are ~85 people working on d-i and that the problems the team might face aren't only related to the lack of manpower (and I don't really want to enter politics) Finally, it seems that some people (well, only one at the moment, but it's enough for to feel the need to precise) though the numbers previously given would dismiss contributions for the active contributors. That wasn't my intention, so I apologize if you are an active contributor in one of that team and thought I dismissed your contribution. If it wasn't clear enough, my point is to show that quite some teams are lacking manpower (some team miss other things too, like leadership, coordination or whatever) and users shouldn't be scared to contribute to them. Those are core teams, without them Debian wouldn't work at all (not to mention derivatives), so it's a good idea to join them. Now, what if you do want to help, but don't know how. On the previous post I gave links to teams website, wiki page or QA page. You should be able to find a mailing list or contact mail you should be able to write to. Just write that you want to offer some help, that you don't know how and where to start. Add what you're interested in, what you find fun, and your technical knowledge. Don't be shy, and you don't need to be a Debian Developer (nor even a Debian Maintainer) to contribute. Thanks!

A few of us are working on spam removal from Debian lists archives. The wiki page linked above explains how to report spam on Debian mailing lists. This is in short as easy as bouncing a mail to a specific address, from your favourite MUA. These "reported spams" then need to be reviewed. Once a given message has been identified as "spam" by enough DD's (there are many false positives in the candidates, particularly in non English-speaking mailing lists), it is removed from the archives. Many mails have already been removed and any help is welcomed. Since Frans Pop launched this for debian-boot, back in May, I use 1 or 2 hours every Sunday to this work. After working on debian-boot only, I gradually worked on reported spams in other lists. As of now, I only have 4 lists where I still have work to do:

• debian-user (115 of 2420 reviewed)
• debian-user-spanish (177 of 1157 reviewed)
• debian-devel (136 of 1075 reviewed)
• debian-chinese-gb (159 of 556 reviewed)

The Chinese and the Spanish ones are tricky because identifying spam there is much less easy (for Chinese, I'm quite conservative and only tag very obvious spam....for Spanish, I read enough of the language to be able to target spam). What about you? Will you be able to help the few of us who work on getting clean archives (noticeably, Sandro Tosi, Giacomo Catenazzi, Cord Beermann, Luk Claes, Frans Pop, Bastian Blank, Luca Falavigna, Michael Koch, Bernd Steinmetz, Thoomas Viehmann, Florian Ernst, Adam D. Barratt, to name thos ewho reviewed more than 1000 mails)? Working on lists in your own language might be a good idea (I'm particularly thinking about lists in German, Spanish, Chinese and French).

debmirror 2.3 should be hitting the mirrors about now. Main change is that it will now use the available diffs to update Contents files, which should give a nice bandwidth reduction for users who mirror those. With that the option --pdiff (for "package diff") no longer really covered its function, so I decided to change it to --diff. There's also a fix for mirroring archives that don't have a Release file. Question for users The option --add-dir has been marked as deprecated (for quite some time now I suspect). I'm considering to remove it in the next release as I cannot see any use cases for it, but it's quite possible I'm missing something and there are still people using it. If you would like that option preserved, then please mail me at debmirror@packages.d.o with an explanation of why and how you use it. Managing the size of a local mirror The archive has grown a lot over the past Debian releases and keeping even a partial local mirror can require quite some disk space. Luckily debmirror offers quite a few options to tune what is mirrored. My own mirror covers testing and unstable 'main' for 6 architectures (i386, amd64, armel, hppa, sparc and s390), no source, no D-I images. It uses only 61G. I say "only" as that's about 33GB less than it could have been without tuning. In other words, I'm saving a bit more than one third! Here are the options I added to achieve this:

--exclude-deb-section='^debug$'
--exclude='/(xen-)?linux-[a-z]+-2\.6[.0-9]*-[-[:alnum:]]*(openvz vserver xen)[-[:alnum:]]*_'
--exclude='(k/kde g/gnome o/openoffice\.org).*/.*_(armel hppa s390)\.deb'
--exclude='(a/axiom/ d/debian-edu-doc/ e/ember( -media)/ e/eclipse(/ -))'
--exclude='(e/erlang g/(gcl(cvs)? ghc6)/ l/llvm(/ -) p/paraview/ o/openturns/)'
--exclude='(s/scalapack(-doc)?/ f/festvox- g/gcc-snapshot/)'
--exclude='(/acl2-books_ /digikam-doc_ /fluid-soundfont-gm_ /deal.ii-doc_)'
--exclude='(/libxmpp4r-ruby-doc_ /lilypond-doc_ /qt4-doc_ /vtk-doc_)'
--exclude='/i18n/Translation-.*\.bz2' --include='/i18n/Translation-(nl de)\.bz2'

And the explanation is:

• I rarely use debug packages and they are relatively big; if I do need one I'll download it manually from a remote mirror.
• I don't run vserver or xen kernels (and if I did I'd probably compile custom kernels anyway). I do want "regular" kernels because of D-I work.
• I doubt I'll ever want to install KDE, GNOME or OpenOffice on my armel, hppa or s390 boxes, but I do want them for the other three arches.
• Selected individual (mostly scientific) source packages that I doubt I'll ever use but use up significant disk space (and bandwidth when updated). These were found by a simple:

  du -s pool/main/*/*   sort -rn   head -n 50
  

• Selected individual huge binary packages (mostly documentation), found using:

  du -s pool/main/*/*/*.deb   sort -rn   head -n 50
  

• I'm only interested in Dutch and German translations of package descriptions. Well, actually I'm not even interested in those, but it's useful to have them for testing debmirror.

Obviously I have nothing against any of the packages that I exclude. It's just that I don't need them.

archfs has been accepted into unstable! I've been working on this package in between other tasks for quite a long time. I based my package on prior packaging work by Adam Sloboda from mentors.debian.net. The upstream package lacks a manpage, and one of the changes I have made from the initial packaging was to replace an XML-authored manpage by Adam with a roff one (based on the processed output of the XML one). I did this because I find authoring roff documents easier than XML ones. Another consequence is the build dependencies a lot simpler. We can see just how simpler thanks to Frans Pops' debtree.

Yay! I've done it: 1160 lines of bash script are now 1215 lines of perl, and:

    'debtree aptitude': 1m2.832s -> 0m0.596s

The new release is available as version 0.9.9 from the debtree web site and has been uploaded for the archive as version 1.0.

---

This was the starting position, the run time for my complete test set:

    real    22m33.583s
    user    18m29.709s
    sys     4m21.320s

I began with a pure language conversion from bash to perl, i.e. I kept the call-outs to dctrl-tools. This allowed me to easily identify problems in the language conversion by running my test suite, without having to worry that a change might have been caused by getting different data. The language conversion itself was fairly straightforward; most time was spent on finding all the little errors made during the conversion. This resulted in "only" a 10% speedup:

    real    20m56.368s
    user    18m3.996s
    sys     2m46.986s

So bash itself isn't even horribly slower than perl, even with all the recursion and starting of subshells for calls to grep, sed, etc. Then I replaced the call-outs to dctrl-tools one by one, adding the dependency on libapt-pkg-perl. And that resulted in the amazing:

    real    0m21.350s
    user    0m19.797s
    sys     0m1.372s

So, from 22 minutes to 21 seconds for 22 graphs, including some pretty complex ones. Not bad. I had to keep a call-out to dctrl-tools for build dependencies as it turned out libapt-pkg-perl does not expose architecture conditions. The full conversion process can be seen in the source repository, which was recently moved from my $HOME on alioth to collab-maint.

debtree 0.8.0, including the new option to display reverse dependencies, is now officially (or rather: unofficially) available. The new feature is of course documented in the man page, but also on the website. And now I think the time has come to port the script to perl. If I manage that I plan to upload the package into the archive as version 1.0. P.S. debtree now also supports generating trivial graphs:

$ debtree --max-depth=0 dpkg

Funnily enough that same graph is less trivial for apt. Support for --max-depth=0 was added to allow to generate graphs showing only reverse dependencies.

I've just uploaded version 2.2 of debmirror, which introduces yet another new feature: mirroring the i18n/Translation files that contain translations of package descriptions. Many thanks to Joerg Jaspert for his quick response to my request to include those files in the Release file. Joerg also implemented the change needed to use the diffs for Contents files but that requires a fairly big code restructuring in debmirror. The package has jumped from version 1.0 to 2.2 in just three weeks (closing 28 bug reports in the process), but I think the changes justify that. Here's an overview.

• Automatic creation and update of suite->codename symlinks (1.0) This also means it no longer makes any difference whether you tell debmirror to mirror sid or unstable.
• Option to cache the mirror state between runs (2.0) This significantly reduces the trashing of the hard disk during mirror updates and cleanup, and improves the efficiency of individual runs. The disk trashing has always been the main reason I did not want to do more than one update per day for my local mirror. Now it hardly matters how many runs I do: almost everything is done based on the cache data. To ensure the mirror stays consistent the cache has a (configurable) maximum life time after which a full check of the mirror will be done, if desired including an md5sum check of all files.
• Significant speed increase for parsing Packages/Sources files (2.0) For my mirror that stage now takes seconds rather than minutes. Additional speed increases should be possible in the stage that fetches the Packages and Sources files.
• Mirroring of "current" Debian Installer images (2.0) Which architectures and suites should be mirrored can be specified independently from the rest of the mirror.
• Mirroring additional files from specific directories (2.1) This allows mirroring of "trace files", of the contents of the ./doc and ./tools directories (which are needed if you want to create CD images using debian-cd, and of the ./indices directory. The transfer method used for this is always rsync, independent of the transfer method used for the rest of the archive. This is a restriction, but rsync is also the only usable option for files for which no real index or checksums are available.
• Mirroring translation files (2.2) As debmirror is primarily intended to be used for local, often partial, mirrors, it is of course possible to mirror only selected languages. Interested only in German and French translations? Simple, just use:

  --i18n --exclude='/Translation-.*\.bz2$' --include='/Translation-(de fr).*\.bz2$'
  

  I've used '(de fr).*' so that also country-specific variants (e.g. fr_FR) will be included.

---

If you're currently using the Lenny version of debmirror and would like to use the new features: the package from unstable can be installed on Lenny without any problems. The changes have been well tested, but I would advice to do use --dry-run after the upgrade to check there are no unexpected problems. One area where you may experience problems is when using debmirror for other archives than the official Debian mirrors. If you do encounter issues then please file a bug report.

---

Note that debmirror is not intended to be used for official mirrors. There are different scripts available for that from the Debian mirror team.

Funny how working on a program immediately inspires to do more. Remember that the initial motivation for debtree was to find out why a package was installed? It can now show that in the dependency graphs! I'm not quite ready to do a new release, but the new version is available from the git repository. Let's start with a simple example (all graphs are based on Lenny).

$ debtree -I --rdeps-depth=3 apt

Only installed packages are displayed here; if the -I option is omitted, debmirror will display all, but that does tend to explode the graphs, especially for common libraries. As for forward dependencies, the color of the arrows indicates Pre-Depends, Depends and Recommends. The reverse dependencies are shown three levels deep (one is default). The graph will always include all direct reverse dependencies (both on the package itself and all virtual packages provided by it. For indirect reverse dependencies there's a cut of that is set at five by default. Example is debconf, that apparently has 9 reverse Pre-Depends and 58 reverse Depends installed on my system. The next one is simply beautiful.

$ debtree -I --rdeps-depth=20 --no-conflicts libcairo2

Because of the --rdeps-depth=20 this shows the full recursion! I was surprised that this graph remained a reasonable size. Apparently no packages depend on the virtual package libcairo, at least none that I have installed. The final one is extreme, and I must confess that I have cheated a bit by suppressing the least interesting reverse depends (which explains why it does not match the numbers from the apt graph).

$ debtree -I -R --no-recommends --no-conflicts debconf

The most interesting thing here is how it shows the debconf-2.0 transition. Most packages depend on 'debconf debconf2.0'; tex-common instead has 'debconf cdebconf', while tasksel and exim4 have both combinations (probably one explicitly in debian/control and the other added by debhelper. ucf is missing the alternative; apparently does not use debhelper (no prizes for guessing who the maintainer is :-). Notice anything about iamerican and ibritish? Yes, they really have a double dependency on 'debconf debconf2.0'. The one thing missing is the version info for versioned dependecies. Not sure yet if I want to add that for reverse dependencies. P.S. SVG versions of the images are available in the same directory as the JPGs.

It's been quite some time (almost two years) since my previous "release" of debtree, but now version 0.7.3 is available. And it still generates very nice graphs :-) The changes are relatively minor: a few nice fixes for corner cases that were not handled correctly, and an update of the default lists of "skip" and "end" packages which help to limit the size of graphs for a fair number of packages I tried (including konqueror and openoffice.org).

---

Reason to revisit debtree was a recent nice mail from a debtree user, but also the current discussions about udev and the FHS. I'm on the side of "let's please keep /usr mountable separately". Mostly because I like a (small) encrypted root with a separate (large) unencrypted /usr'. I'm also increasingly unhappy with the default size of Debian's desktop installs, especially now that it looks as if Squeeze will see installation of Recommends by default by tasksel (and thus Debian Installer). For comparison, the size of a default Gnome desktop install for Etch was 1360MB; for Lenny it is 1830MB; for Squeeze it looks like it will be well over 3000MB! Remember that for Sarge we installed both Gnome and KDE from CD1 with both together taking 1390MB? Sure, some of that is real functionality, but a lot is also (IMO) redundant visual effects that only serve to slow the desktop down and junk needed to do stuff automagically. And a heck of a lot is duplicated functionality. One of the main reasons I switched to Linux was because it gave me back control over my systems, but with KDE4 and pervasive stuff like hal and all the various "kits" Linux is on a fast track that's giving priority to flashiness over real functionality and eroding that control. Here's a fairly default dependency graph for hal (click for full image). Looks reasonable, right? But that's only because most major dependencies, such as dbus, policykit and pm-utils have been pruned. Here's a complete graph, with only libc6 omitted (full image is 1.5MB). Truly a tangled web. Scary. One can also look at it from the other side. Today I upgraded my sid chroot and found I suddenly needed to install libavahi-client3, libavahi-common3, libavahi-common-data and libdbus-1-3. Why? Reason turned out to be libcups2, so I checked if I really needed that. And here's why I do. Most of these dependencies of libgtk2.0-0 I can understand, but isn't gtk supposed to be a graphical toolkit library? Couldn't printing support be implemented in some more specialized Gnome printing toolkit library? But I'm probably missing something. Anyway, now that I have a bit more perl experience through my recent work on debmirror, maybe I should finally port debtree from shell script to perl...

---

See the debtree home page for a full overview of how to read the graphs, but here's a quick intro. Purple arrows are Pre-Depends, blue are Depends and black are Recommends; green connections show Provides. The green packages are currently installed in my sid chroot, while the white ones are not. The diamonds show where the graph has been pruned: dependencies for these packages are not shown.

As a past member of the listmaster team, this is a goal I have to support. I did some work myself a few years ago to clean out at least the most offensive images from the archive. And I can tell you there were a number of really gross ones. This was mostly manual work, replacing the spams by placeholder messages. Since then the listmaster team has implemented an excellent toolset for nominating messages as spam, reviewing the nominations and removing confirmed spam from the archive. My current contribution is twofold: Plug-in that allows reporting new list spam from KMail It's not actually a plug-in, but just uses the filter functionality of KMail. I've documented two alternative filters developed for KMail 1.9.9 (from KDE 3.5). Possibly they can also be (adapted to be) used with KMail from KDE 4, but that has not been tested. There are plug-ins available for several Mail User Agents (MUAs), with a few still to be developed. Spam cleaning campaign for the debian-boot list A few weeks ago I sent out a request for help to clean "our" archive. The response has been great. The work is [tracked on a Wiki page[(http://wiki.debian.org/DebianInstaller/SpamClean) and has already resulted in the removal of 676 spams. By the end of this week I expect that number to be doubled. If you'd like to start a similar project for your own favorite list, I'd suggest you start by reading through the thread linked above.

---

Update: I was wrong, the number was almost tripled: from 676 to 1801!

Ingredients:

• some lame DNS server
• logcheck
• spamassassin

The last couple of days I've been plagued by some DNS errors that kept showing up in the logcheck mails for my home server which I was busy migrating from one box to another, doing an upgrade from etch/i386 to lenny/amd64 at the same time. So, plenty of stuff going on to confuse the issue. I kept getting the following messages every hour (anonymized):

named: connection refused resolving 'somedomain.org/NS/IN': xxx.yyy.zzz.nnn#53
named: connection refused resolving 'somedomain.org/NS/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns1.somedomain.org/AAAA/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns2.somedomain.org/AAAA/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns1.somedomain.org/AAAA/IN': xxx.yyy.zzz.nnn#53
named: connection refused resolving 'ns2.somedomain.org/AAAA/IN': xxx.yyy.zzz.nnn#53

The times were fairly regular: once just before the hour, most 2 minutes after. I fetch mail at around that time, but also at other times, so possible but unlikely. The 2 minutes after was the first real clue: some cron job maybe? After disabling logcheck the messages no longer appeared in the log. Enable it again, and they were back. Additional confusion was caused by the fact that the domain had "debian" in its name, but it was somewhere obscure. So why was logcheck causing a lookup for that domain? This did confuse me enough to waste some time looking for some silly weird (default) configuration problem in some package. Enter spamassassin. Apparently that was parsing the message body, recognized "somedomain.org" as a host name, and proceded to do a DNS lookup as validity check. So we have the following loop, started off by something causing an initial DNS lookup for the domain, which fails and gets logged:

• logcheck reports the failure during its next check
• spamassassin processes the logcheck mail, spots the domain name and does a new set of lookups, which fail and get logged
• logcheck reports the failures during its next check
• ...

Duh. I remember struggling with probably the same problem a couple of years ago, but then it was a lot more severe: masses of repeating DNS errors for obscure domains. At that time I failed to get to the bottom of it and ended up just ignoring the errors by adding the following option in my bind9 configuration:

logging  
    category lame-servers   null;  ;
 ;

Anyway, now I just no longer pass logcheck mails through spamassassin. (Although filtering out these DNS errors in bind9 can be perfectly valid.)

Ingredients:

• some lame DNS server
• logcheck
• spamassassin

The last couple of days I've been plagued by some DNS errors that kept showing up in the logcheck mails for my home server which I was busy migrating from one box to another, doing an upgrade from etch/i386 to lenny/amd64 at the same time. So, plenty of stuff going on to confuse the issue. I kept getting the following messages every hour (anonymized):

named: connection refused resolving 'somedomain.org/NS/IN': xxx.yyy.zzz.nnn#53
named: connection refused resolving 'somedomain.org/NS/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns1.somedomain.org/AAAA/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns2.somedomain.org/AAAA/IN': xxx.yyy.zzz.mmm#53
named: connection refused resolving 'ns1.somedomain.org/AAAA/IN': xxx.yyy.zzz.nnn#53
named: connection refused resolving 'ns2.somedomain.org/AAAA/IN': xxx.yyy.zzz.nnn#53

The times were fairly regular: once just before the hour, most 2 minutes after. I fetch mail at around that time, but also at other times, so possible but unlikely. The 2 minutes after was the first real clue: some cron job maybe? After disabling logcheck the messages no longer appeared in the log. Enable it again, and they were back. Additional confusion was caused by the fact that the domain had "debian" in its name, but it was somewhere obscure. So why was logcheck causing a lookup for that domain? This did confuse me enough to waste some time looking for some silly weird (default) configuration problem in some package. Enter spamassassin. Apparently that was parsing the message body, recognized "somedomain.org" as a host name, and proceded to do a DNS lookup as validity check. So we have the following loop, started off by something causing an initial DNS lookup for the domain, which fails and gets logged:

• logcheck reports the failure during its next check
• spamassassin processes the logcheck mail, spots the domain name and does a new set of lookups, which fail and get logged
• logcheck reports the failures during its next check
• ...

Duh. I remember struggling with probably the same problem a couple of years ago, but then it was a lot more severe: masses of repeating DNS errors for obscure domains. At that time I failed to get to the bottom of it and ended up just ignoring the errors by adding the following option in my bind9 configuration:

logging  
    category lame-servers   null;  ;
 ;

Anyway, now I just no longer pass logcheck mails through spamassassin. (Although filtering out these DNS errors in bind9 can be perfectly valid.)

Well, no, neither FOSDEM nor Debian are dead. But FOSDEM '09 is gone, over, and dealt with. It was a breeze, for the most part. I'm still not very happy with the booth; that needs to be done better next year. Help and suggestions in that area are more than welcome. One thing that more than deserves a follow-up is Lucas' post about FOSDEM:

On a more sad note, the worst talk of the week-end was without any possible doubt Frans Pop's release team bashing. Nobody is claiming that the release management of the lenny release cycle was perfect: there's always room for improvement. But given the context and the constraints, I think that they did a very good job. Frans' talk boiled down to: "The release team doesn't know what they are doing, I would have done much better because I'm so qualified."

As the person responsible for allowing Frans on the schedule in the first place, while being fully aware of the relationship between Frans and the release team (not at first, but certainly in time to kick him off if I'd have wanted to), I'd like to comment on that. First of all, I do not agree that the last statement in the above is true. Frans showed a few stories of things that went on in the release team, and gave his opinion on what he believed went wrong. He also explicitly said, at the beginning of the talk, that none of the talk was meant personally; that he wanted to offer some constructive criticism instead. I believe he did not fail in doing that, but of course YMMV. Secondly, and more importantly, I do not believe it is healthy for Debian (or any project, for that matter) to reject criticism. Indeed, nobody is claiming perfection. I do not believe any venue where talks can be had should be a good news show. People in a position of power not just the release team, but also, say, the DPL, ftp-masters, buildd maintainers and whatnot have received our trust to do what they need to do to the best of their abilities. If someone in the project would believe that I can significantly improve my work as buildd maintainer, it is not just their right, but indeed their duty to inform me of that fact. This is exactly what Frans was attempting to do, and there is nothing wrong with that. It is also not as if he's not tried reasoning with the release team first. He has made suggestions, which have gotten ignored. I feel that talking to more people about what he feels is right, to see whether they agree with him, is the next logical step to take, and that this it is exactly what Frans was attempting to do at FOSDEM. Having said that, I agree that finishing the talk late was a very bad thing. If anything, a talk on a subject like this should have more, not less, time for discussion. So while I do not agree that his intentions were wrong, I do agree that the execution could have been better. There, that was criticism too. Now, what's next? Oh yes, suggestions. If people have suggestions on how to improve the Debian presence at FOSDEM next year (especially, as above, ideas for creative use of the booth would be welcome), then please send me an email, making sure the subject contains the word 'FOSDEM', so my mailfilters know what to do with it. You'll preferably do so now, while FOSDEM is still somewhat fresh in your memory; I'll take notes and use those for doing better next year. Thanks,

Of course, I was in Brussels this week-end, for FOSDEM. I gave a talk about Ultimate Debian Database (slides here) in the Debian devroom. The conclusion was UDD is ready, go play with it! so you know what you should do now! FOSDEM in general was great and huge (see the video from Quim Gil if you still doubt that) as usual. On a more sad note, the worst talk of the week-end was without any possible doubt Frans Pop s release team bashing. Nobody is claiming that the release management of the lenny release cycle was perfect: there s always room for improvement. But given the context and the constraints, I think that they did a very good job. Frans talk boiled down to: The release team doesn t know what they are doing, I would have done much better because I m so qualified. Giving such talks at FOSDEM, in front of an audience with many people not involved in Debian development, is really insulting. To make things worse, he finished the talk late, not leaving any time for questions/discussion, so the audience might be left with the impression that his opinions are representative of the opinions of DDs.

In August I got a very nice HP 2510p notebook which is now my main system for development. This took a while for two reasons. First of all the system did not resume 100% reliably. This has now been solved, although the final patches needed for that will only be in 2.6.29, but that's no problem as I run upstream kernels anyway (I do quite a bit of kernel testing). Kudos have to go to Rafael J. Wysocki who has been doing a huge amount of work to improve the suspend/resume code in the kernel. Second of all I wanted a docking station so I could continue to use my 19" monitor, with the laptop's LCD as second display. I bought the docking station in December. The challenge then was to automatically (de)activate the external display when the notebook is (un)docked. Unfortunately there are no ACPI events, but the hp-wmi module (written by Mattew Garrett) sends docking events to the input subsystem. I wrote a small program to catch these events and a script that uses xrandr to switch displays. There were two issues with that setup. The first docking event was getting lost, but I managed to fix that. And the X server would crash when starting some applications (einstein and virtualbox) after undocking, but there's a patch for that too now. The notebook is now really well supported and stable.

• suspend/resume works completely reliably
• the docking station works nicely and so does the dual display setup
• wireless works nicely
• the SD card reader works (was used to develop support for MMC/SD cards in Debian Installer)
• the accelerometer works (so I can play Tux Racer and Neverball by tilting the notebook) using the lis3lv02d module, and Pavel Machek recently even added freefall detection, including example code to park the hard disk (targeted for 2.6.30)
• the fingerprint reader works, though I'm not sure I actually want to use that for logging on to the system

The system is currently running Debian/lenny with a KDE desktop and a 2.6.29-rc3 kernel. Working with upstream developers to get this far has really been worthwhile, and fun.

There have been 470 mails during the last month in the DFSG violations threads on -vote@, but only 10 posters have contributed more than 10 mails so far:

85 Robert Millan
51 Manoj Srivastava
18 Pierre Habouzit
18 Josselin Mouette
16 Thomas Bushnell BSG
14 Stephen Gran
13 Frans Pop
13 Ean Schuessler
13 Adeodato Simo
12 Russ Allbery

Is someone working on a summary of the discussions? I would really hate it if we were asked to vote on this, with a “for details, see the -vote@ archives” footnote. (Robert Millan sounds like a perfect candidate for this task :-) )

When the Debian installer starts, it will normally ask you what language you want to install in and gives you a really long list of languages to choose from. Unfortunately, that's not how it works when you install on a headless NAS device. The reason for this is that installations on NAS devices are done via SSH and the installer normally brings the network up after asking the user for their language. So we'd simply skip the language question and go with English. When Timo Jyrinki recently mentioned that he couldn't install in Finnish, Frans Pop pointed out that localechooser has changed a lot since etch and that it should now be possible to have the language question after setting up the network. This turned out to be correct and I managed to choose a different language but the installer still showed everything in English. Frans reminded me that the installer drops all translations that are not necessary but unfortunately this happens too early in our case. He pointed me to a variable that determines whether translations will be dropped. So in lenny translations will not be dropped on NAS devices that have enough RAM and users will be asked when they connect to the installer via SSH what language they'd like to install in.

After a short discussion time, my proposals have been ACK'ed and we will have 63 languages supported, including English, in Debian Installer for Lenny. Etch had 58 supported languages. The final winners are (alphabetical order of ISO code): Amharic, Arabic, Belarusian, Bulgarian, Bengali, Bosnian, Catalan, Czech, Welsh, Danish, German, Dzongkha, Greek, English, Esperanto, Spanish, Basque, Finnish, French, Irish, Galician, Gujarati, Hebrew, Hindi, Croatian, Hungarian, Indonesian, Italian, Japanese, Georgian, Khmer, Korean, Kurdish, Lithuanian, Latvian, Macedonian, Malayalam, Marathi, Norwegian Bokm l, Nepali, Dutch, Norwegian Nynorsk, Punjabi, Polish, Portuguese, Brazilian Portuguese, Romanian, Russian, Northern Sami, Slovak, Slovenian, Albabian, Serbian, Swedish, Tamil, Thai, Tagalog, Turkish, Ukrainian, Vietnamese, Wolof, Simplified Chinese, Traditional Chinese Newcomers for Lenny are: Amharic, Welsh (back), Irish, Marathi, Northern Sami, Serbian We lost Estonian which was in Etch. Those that missed the deadline are of course all other languages of the world. We will put focus on languages where an effort started at some moment but could not be complete enough: Afrikaans, Estonian, Persian, Armenian, Icelandic, Kazakh, Kannada, Kashmiri, Lao, Malagasy, Malay, Sanskrit, Secwepemctsin, Telugu, Urdu, Xhosa Many thanks to all translators for this final effort. Thanks also to all people who urgently popped up last week to complete the translations for languages that were "orphaned". I hope this will bring us more translators...:-) I keep special thanks to Frans Pop here. He is, along with me, the author of the code that allows us to split D-I translations in "sublevels", allowing translators to focus on the most "important" messages. He also implemented prior warnings when users pick up a language where some less important screens aren't translated. This also allows us to more easily keep partly complete translations, or activate languages earlier. Without this, 11 languages should have been dropped.

One thing that's annoying about the Debian installer on the NSLU2, as Joey Hess pointed out a few months ago when he reinstalled his NSLU2, is that you have to manually select some installer modules. The reason for this is that the NSLU2 only has 32 MB of RAM and thus Debian installer runs in lowmem mode in which less functionality is enabled by default. As a result of this, you have to select partman-auto, partman-ext3 and usb-storage-modules from a list of additional installer modules to load so the installer will recognize your USB disk, offer guided partitioning and format the disk with ext3. When Joey submitted his installation report, Frans Pop suggested that we could put a list of installer modules we want to have installed automatically in /var/cache/anna/include. I finally got around to playing around with this yesterday and while this specific solution won't work on lowmem systems we can use anna-install to automatically queue installer modules for installation. Since anna-install works, I put some functionality into the installer today to automatically load required installer modules on the Linksys NSLU2 and on Cobalt machines. This change is good for users because they don't have to select some modules during the installation. I'm a little bit worried that existing users of the installer on the NSLU2 will be confused when they don't see the modules in the list anymore, but I'll update the documentation accordingly.